home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / p_man / cat5 / refcnt.z / refcnt
Encoding:
Text File  |  2002-10-03  |  19.0 KB  |  397 lines

  1.  
  2.  
  3.  
  4. rrrreeeeffffccccnnnntttt((((5555))))                                                            rrrreeeeffffccccnnnntttt((((5555))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      MMMMeeeemmmmoooorrrryyyy RRRReeeeffffeeeerrrreeeennnncccceeee CCCCoooouuuunnnntttteeeerrrrssss - Analysis of memory access patterns
  10.  
  11.  
  12. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  13.      The Origin 2000/200 hardware provides memory reference counters to assist
  14.      application programmers in tuning their algorithms for optimal
  15.      performance on a NUMA system. These counters are capable of unveiling the
  16.      exact memory reference patterns exhibited by an application or a specific
  17.      algorithm, enabling the programmer to optimize the application data
  18.      layout and to provide specific memory placement hints to the Operating
  19.      System in order to maximize cache utilization and locality of memory
  20.      access, therefore achieving best memory access performance.
  21.  
  22.      Note that this is an Origin 2000/200 capability only, and does not apply
  23.      to other Origin platforms.
  24.  
  25.  
  26. IIIIMMMMPPPPLLLLEEEEMMMMEEEENNNNTTTTAAAATTTTIIIIOOOONNNN
  27.    HHHHaaaarrrrddddwwwwaaaarrrreeee RRRReeeeffffeeeerrrreeeennnncccceeee CCCCoooouuuunnnntttteeeerrrrssss
  28.      Origin 2000 and Origin 200 systems provide a set of counters for every 4
  29.      KB hardware page of memory. The number of counters per set depends on the
  30.      number of nodes in the system: for systems with less than 64 nodes (that
  31.      is 128 processors) a counter set has one counter per node, and for
  32.      systems with more than 64 nodes a counter set has one counter for every 8
  33.      nodes. For systems with 64 or less nodes, each counter in a counter set
  34.      counts the numbers of references from each of the nodes. Thus, the
  35.      application programmer can tell exactly how many references have been
  36.      issued to a page from each node in the system. For systems with more than
  37.      64 nodes, each counter in a  counter set corresponds to the number of
  38.      references to a page issued by a group of 8 nodes.
  39.  
  40.      Note that a hhhhaaaarrrrddddwwwwaaaarrrreeee ppppaaaaggggeeee is not equivalent to a bbbbaaaasssseeee ssssooooffffttttwwwwaaaarrrreeee ppppaaaaggggeeee (or
  41.      just ppppaaaaggggeeee). A hhhhaaaarrrrddddwwwwaaaarrrreeee ppppaaaaggggeeee defines the granularity at with the hardware
  42.      does reference counting and other hardware operations; a base software
  43.      page is the smallest unit of memory that can be mapped by user processes
  44.      via the Translation Look-aside Buffer or the Page Tables. For Origin 2000
  45.      and Origin 200 systems a hardware page, and therefore the memory
  46.      reference counting granularity, is 4 KB; and a base sofware page is 16KB.
  47.  
  48.      For example, consider an 8 node (16 cpu) Origin 2000 system with the
  49.      memory configuration shown in the table below. This table shows the
  50.      number of hardware pages (equivalent to the number of counter sets), the
  51.      number of total counters, and the number of base software pages per node.
  52.      For this configuration of 8 nodes, each counter set has 8 counters (one
  53.      per node).
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. rrrreeeeffffccccnnnntttt((((5555))))                                                            rrrreeeeffffccccnnnntttt((((5555))))
  71.  
  72.  
  73.  
  74.                                   Memory Configuration
  75.                                   Hardware   Counter    Total          Base
  76.                         Memory     Pages      Sets     Counters   Software Pages
  77.         Module   Slot   [bytes]   Mem/4Kb    1/Hpage    8*Sets       Mem/16Kb
  78.           1       n1     512M       128K      128K      1024K          32K
  79.           1       n2     256M        65K       65K       512K          16K
  80.           1       n3     256M        65K       65K       512K          16K
  81.           1       n4     512M       128K      128K      1024K          32K
  82.           2       n1     256M        65K       65K       512K          16K
  83.           2       n2      64M        16K       16K       128K           4K
  84.           2       n3      64M        16K       16K       128K           4K
  85.           2       n4     256M        65K       65K       512K          16K
  86.  
  87.  
  88.      The length of each counter also depends on the system configuration.  For
  89.      systems with more than 16 nodes (32 cpus), the counters have a length of
  90.      19 bits (maximum count is 0x7ffff). For systems with less than 16 nodes,
  91.      the length of the counters depends on the the kind of directory SIMMS
  92.      installed on the machine. If SSSSTTTTAAAANNNNDDDDAAAARRRRDDDD SSSSIIIIMMMMMMMMSSSS are installed, then the
  93.      counters are 11-bit (maximum count 0x7ff); if PPPPRRRREEEEMMMMIIIIUUUUMMMM SSSSIIIIMMMMMMMMSSSS are
  94.      installed, then the counters are 19-bit.
  95.  
  96.  
  97.    SSSSooooffffwwwwaaaarrrreeee EEEExxxxtttteeeennnnddddeeeedddd RRRReeeeffffeeeerrrreeeennnncccceeee CCCCoooouuuunnnntttteeeerrrrssss
  98.      The hardware counters peg when they reach their maximum count. This is a
  99.      problem for the 11-bit counters that would peg after only 0x7ff (2047)
  100.      references to a page from one node. To allow application programmers to
  101.      keep track of memory references beyond this small number, Cellular Irix
  102.      provides SSSSooooffffttttwwwwaaaarrrreeee EEEExxxxtttteeeennnnddddeeeedddd MMMMeeeemmmmoooorrrryyyy RRRReeeeffffeeeerrrreeeennnncccceeee CCCCoooouuuunnnntttteeeerrrrssss.
  103.  
  104.      The Extended Counters are implemented as an array of 32-bit counters that
  105.      closely mirror the hardware counters, extending their maximum count to
  106.      2^32.  The hardware counters are setup in such a way that they send an
  107.      interrupt when they reach a threshold close to the maximum count. When
  108.      this interrupt is received by the operating system, the current hardware
  109.      counter count is added to the corresponding software extended counter
  110.      mirror, and the hardware counter is reset to 0. This uuuuppppddddaaaatttteeee procedure is
  111.      performed for complete counter sets, that is, when we receive the
  112.      overflow interrupt we not only update the counter that is overflowing,
  113.      but also all the other counters in its set.
  114.  
  115.  
  116. IIIINNNNTTTTEEEERRRRFFFFAAAACCCCEEEE
  117.    EEEEnnnnaaaabbbblllliiiinnnngggg RRRReeeeffffeeeerrrreeeennnncccceeee CCCCoooouuuunnnnttttiiiinnnngggg
  118.      To enable reference counting for a section of virtual memory within an
  119.      application, the programmer can use a Policy Module (mmci(5)) with the
  120.      migration policy set to "MigrationRefcnt".
  121.  
  122.  
  123.    HHHHaaaarrrrddddwwwwaaaarrrreeee RRRReeeeffffeeeerrrreeeennnncccceeee CCCCoooouuuunnnntttteeeerrrrssss
  124.      The hardware reference counters for a section of an address space can be
  125.      accessed using pppprrrrooooccccffffssss (proc(4)). The ioctl command code used for this
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. rrrreeeeffffccccnnnntttt((((5555))))                                                            rrrreeeeffffccccnnnntttt((((5555))))
  137.  
  138.  
  139.  
  140.      purpose is PIOCGETSN0REFCNTRS. The third argument is used to specify both
  141.      the virtual address space range we need the counters for, and the buffer
  142.      where the system should copy the counter values to. This argument is of
  143.      type sn0_refcnt_args_t, as defined in <sys/SN/hwcntrs.h>:
  144.  
  145.           typedef struct sn0_refcnt_args {
  146.                   caddr_t             vaddr;
  147.                   long                len;
  148.                   sn0_refcnt_buf_t*   buf;
  149.           } sn0_refcnt_args_t;
  150.  
  151.  
  152.      The first field vvvvaaaaddddddddrrrr is the base of the virtual address space range, the
  153.      field lllleeeennnn is the corresponding length in bytes, and the field bbbbuuuuffff is a
  154.      pointer to a user buffer where the system will store the counter values
  155.      and additional information. This buffer is an array of elements of type
  156.      sn0_refcnt_buf_t, where each element corresponds to the counter
  157.      information associated with one hardware page:
  158.  
  159.           typedef struct sn0_refcnt_buf {
  160.                sn0_refcnt_set_t   refcnt_set;
  161.                __uint64_t         paddr;
  162.                   __uint64_t         page_size;
  163.                   cnodeid_t          cnodeid;
  164.           } sn0_refcnt_buf_t;
  165.  
  166.  
  167.      The field rrrreeeeffffccccnnnntttt____sssseeeetttt contains the set of counters associated with the
  168.      virtual address passed via ssssnnnn0000____rrrreeeeffffccccnnnntttt____aaaarrrrggggssss, ppppaaaaddddddddrrrr is the address of the
  169.      physical page associated with this virtual address, ppppaaaaggggeeee____ssssiiiizzzzeeee is the page
  170.      size being used to map it, and ccccnnnnooooddddeeeeiiiidddd is the physical page home node,
  171.      expressed in terms of _C_o_m_p_a_c_t _N_o_d_e _I_d_e_n_t_i_f_i_e_r_s which can be mapped back
  172.      to node names using the command topology(1).  The rrrreeeeffffccccnnnntttt____sssseeeetttt type is
  173.      defined by
  174.  
  175.           typedef struct sn0_refcnt_set {
  176.                   refcnt_t    refcnt[SN0_REFCNT_MAX_COUNTERS];
  177.                   __uint64_t  flags;
  178.           } sn0_refcnt_set_t;
  179.  
  180.  
  181.      The field rrrreeeeffffccccnnnntttt is the actual set of counters (one counter per node),
  182.      and ffffllllaaaaggggssss is a state vector reserved for future use.  The counters in
  183.      rrrreeeeffffccccnnnntttt are ordered according to the _C_o_m_p_a_c_t _N_o_d_e _I_d_e_n_t_i_f_i_e_r_s, also known
  184.      as ccccnnnnooooddddeeeeiiiiddddssss (numa(5)).
  185.  
  186.  
  187.  
  188.    SSSSooooffffttttwwwwaaaarrrreeee EEEExxxxtttteeeennnnddddeeeedddd RRRReeeeffffeeeerrrreeeennnncccceeee CCCCoooouuuunnnntttteeeerrrrssss
  189.      The extended reference counters for a section of an address space can be
  190.      accessed using pppprrrrooooccccffffssss (proc(4)), using practically the same interface
  191.      defined above for the hardware reference counters.  The ioctl command
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. rrrreeeeffffccccnnnntttt((((5555))))                                                            rrrreeeeffffccccnnnntttt((((5555))))
  203.  
  204.  
  205.  
  206.      code used for this purpose is PIOCGETSN0EXTREFCNTRS (the difference
  207.      between this command and the command used for the hardware counters is
  208.      the prefix EXT before the word REFCNTRS). The third argument is used to
  209.      specify both the virtual address space range we need the counters for,
  210.      and the buffer where the system should copy the counter values to. This
  211.      argument is of type sn0_refcnt_args_t, as defined in <sys/SN/hwcntrs.h>:
  212.  
  213.           typedef struct sn0_refcnt_args {
  214.                   caddr_t             vaddr;
  215.                   long                len;
  216.                   sn0_refcnt_buf_t*   buf;
  217.           } sn0_refcnt_args_t;
  218.  
  219.  
  220.      The first field vvvvaaaaddddddddrrrr is the base of the virtual address space range, the
  221.      field lllleeeennnn is the corresponding length in bytes, and the field bbbbuuuuffff is a
  222.      pointer to a user buffer where the system will store the counter values
  223.      and additional information. This buffer is an array of elements of type
  224.      sn0_refcnt_buf_t, where each element corresponds to the counter
  225.      information associated with one hardware page:
  226.  
  227.           typedef struct sn0_refcnt_buf {
  228.                sn0_refcnt_set_t   refcnt_set;
  229.                __uint64_t         paddr;
  230.                   __uint64_t         page_size;
  231.                   cnodeid_t          cnodeid;
  232.           } sn0_refcnt_buf_t;
  233.  
  234.  
  235.      The field rrrreeeeffffccccnnnntttt____sssseeeetttt contains the set of counters associated with the
  236.      virtual address passed via ssssnnnn0000____rrrreeeeffffccccnnnntttt____aaaarrrrggggssss, ppppaaaaddddddddrrrr is the address of the
  237.      physical page associated with this virtual address, ppppaaaaggggeeee____ssssiiiizzzzeeee is the page
  238.      size being used to map it, and ccccnnnnooooddddeeeeiiiidddd is the physical page home node,
  239.      expressed in terms of _C_o_m_p_a_c_t _N_o_d_e _I_d_e_n_t_i_f_i_e_r_s which can be mapped back
  240.      to node names using the command topology(1).  The rrrreeeeffffccccnnnntttt____sssseeeetttt type is
  241.      defined by
  242.  
  243.           typedef struct sn0_refcnt_set {
  244.                   refcnt_t    refcnt[SN0_REFCNT_MAX_COUNTERS];
  245.                   __uint64_t  flags;
  246.           } sn0_refcnt_set_t;
  247.  
  248.  
  249.      The field rrrreeeeffffccccnnnntttt is the actual set of counters (one counter per node),
  250.      and ffffllllaaaaggggssss is a state vector reserved for future use.  The counters in
  251.      rrrreeeeffffccccnnnntttt are ordered according to the _C_o_m_p_a_c_t _N_o_d_e _I_d_e_n_t_i_f_i_e_r_s, also known
  252.      as ccccnnnnooooddddeeeeiiiiddddssss (numa(5)).
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.                                                                         PPPPaaaaggggeeee 4444
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. rrrreeeeffffccccnnnntttt((((5555))))                                                            rrrreeeeffffccccnnnntttt((((5555))))
  269.  
  270.  
  271.  
  272.    MMMMeeeemmmmoooorrrryyyy MMMMaaaappppppppeeeedddd SSSSooooffffttttwwwwaaaarrrreeee EEEExxxxtttteeeennnnddddeeeedddd RRRReeeeffffeeeerrrreeeennnncccceeee CCCCoooouuuunnnntttteeeerrrrssss
  273.      The extended reference counters can also be accessed by mmapping them to
  274.      a user application's virtual address space. This interface is intended to
  275.      be used by performance tools that provide a global system view rather
  276.      than a localized process view.
  277.  
  278.      This interface is based on a device driver associated with a device that
  279.      represents the reference counters for each node in an Origin system.
  280.      Here is the list of reference counter devices for an 8 node system:
  281.  
  282.           /hw/module/2/slot/n1/node/refcnt
  283.           /hw/module/2/slot/n2/node/refcnt
  284.           /hw/module/2/slot/n3/node/refcnt
  285.           /hw/module/2/slot/n4/node/refcnt
  286.           /hw/module/1/slot/n1/node/refcnt
  287.           /hw/module/1/slot/n2/node/refcnt
  288.           /hw/module/1/slot/n3/node/refcnt
  289.           /hw/module/1/slot/n4/node/refcnt
  290.  
  291.  
  292.      To map the counters in a node, a user needs to open the refcnt device for
  293.      the node, then using the open file descriptor the user needs to obtain
  294.      information regarding the counters, defined by rcb_info_t in
  295.      <sys/SN/hwcntrs.h>, using ioctl(fd, RCB_INFO_GET, &rcbinfo).
  296.  
  297.           typedef struct rcb_info {
  298.                   __uint64_t  rcb_len;                  /* total refcnt buffer len in bytes */
  299.  
  300.                   int         rcb_sw_sets;              /* number of sw counter sets in buffer */
  301.                   int         rcb_sw_counters_per_set;  /* sw counters per set -- numnodes */
  302.                   int         rcb_sw_counter_size;      /* sizeof(refcnt_t) -- size of sw cntr */
  303.  
  304.                   int         rcb_base_pages;           /* number of base pages in node */
  305.                   int         rcb_base_page_size;       /* sw base page size */
  306.                   __uint64_t  rcb_base_paddr;           /* base physical address for this node */
  307.  
  308.                   int         rcb_cnodeid;              /* cnodeid for this node */
  309.                   int         rcb_granularity;          /* hw page size used for counter sets */
  310.                   uint        rcb_hw_counter_max;       /* max hwcounter count (width mask) */
  311.                   int         rcb_diff_threshold;       /* current node differential threshold */
  312.                   int         rcb_abs_threshold;        /* current node absolute threshold */
  313.                   int         rcb_num_slots;            /* physmem slots */
  314.  
  315.           } rcb_info_t;
  316.  
  317.  
  318.      Physical memory in a node is not always contiguous, and therefore
  319.      additional information is necessary to determine the counter buffer
  320.      location associated with a physical page. Physical memory within a node
  321.      is divided into a number of contiguous sections called "slots". The slot
  322.      configuration for a node can be obtained using ioctl(fd, RCB_SLOT_GET,
  323.      slotconfig), where slot config is of type rcb_slot_t defined in
  324.  
  325.  
  326.  
  327.                                                                         PPPPaaaaggggeeee 5555
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. rrrreeeeffffccccnnnntttt((((5555))))                                                            rrrreeeeffffccccnnnntttt((((5555))))
  335.  
  336.  
  337.  
  338.      <sys/SN/hwcntrs.h>.
  339.  
  340.           typedef struct rcb_slot {
  341.                   __uint64_t  base;    /* Base physical address for slot */
  342.                   __uint64_t  size;    /* Size of slot in bytes */
  343.           } rcb_slot_t;
  344.  
  345.  
  346.  
  347.  
  348.  
  349. CCCCAAAAVVVVEEEEAAAATTTTSSSS
  350.      The reference counters when enabled can consume a considerable amount of
  351.      memory space for the per-node reference tables.
  352.  
  353.      The reference counters are not virtualized. This means that if a process
  354.      starts paging, or its pages start migrating, the counter set associated
  355.      with a virtual page will change.
  356.  
  357.      The extended memory reference counters may be out of sync with the
  358.      hardware reference counters by up to the hardware reference counter
  359.      maximum count (2047 for 11-bit counters and 524287 for 19-bit counters).
  360.  
  361.  
  362. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  363.      For more information, see numa(5), mmci(5), proc(4), migration(5), sn(1),
  364.      nstats(1)
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.                                                                         PPPPaaaaggggeeee 6666
  394.  
  395.  
  396.  
  397.